1. Field of the Invention
The present invention relates generally to service adaptation and, more particularly, to adapt service entities using a declarative approach in a service framework.
2. Description of the Related Art
Service entities (e.g., Web services, software applications, software components, software modules, software entities, and the like) provide flexible building blocks of enterprise business systems. As a standard means of interoperating between different software applications that run on a variety of platform and/or frameworks, service entities can be combined in a loosely coupled way in order to achieve complex operations. Typically, descriptions of service entities are centrally stored and are accessible through standards-based mechanisms (e.g., transmission control protocol/internet protocol (TCP/IP), hyper text transfer protocol (HTTP), file transfer protocol (FTP), simple object access protocol (SOAP), common object request broker architecture (CORBA), remote procedure call (RPC), and the like) to enterprise applications that would like to invoke the service entities.
However, service entities are often designed to expose functionality of individual applications and may be too limited to be efficient building blocks for enterprise-wide business processes. A solution has been the migration to a Service Oriented Architecture (SOA). The SOA is an open architecture middleware, which builds on the benefits provided by service entities. An example of an SOA is Enterprise Service Framework (ESF) of SAP AG of Walldorf, Germany (SAP).
In a service framework (e.g., ESF) that includes service entities, a client can call a service entity from a service entity provider through an Application Program Interface (API). As used herein, the term “service framework” refers to a defined support structure in which software systems and applications, such as Web services, can be developed, organized, compiled, deployed, customized, run, and/or executed. A service framework may include computer hardware, computer networks, user interfaces, support programs, code libraries, code repositories, scripting language, or other components to help develop and glue together the different components of one or more software systems or applications. The service entity provider allows the instantiation of business objects in response to the API call. As used herein, the term “instantiate” means, in an object oriented programming (OOP) environment, an object of a particular class, and, more generally, includes deploying, customizing, running and/or executing an application.
An “object” means a software bundle of variables (e.g., data) and related methods (e.g., business logic). For example, in object-oriented programming, an object is a concrete realization (i.e., “instance”) of a class that consists of data and the operations associated with that data. Software “components” or “entities” (e.g., service entities and Web service entities) generally take the form of objects, in some binary or textual form, and adhere to one or more interface description languages (IDL), so that the components or entities may exist autonomously from other components or entities in a computer system. The phrase “business object” refers to a software bundle of variables and related methods that can be used to encapsulate business logic that describes a business process or task. For example, a client can call the API of a service entity provider through a communication mechanism, such as the Internet or intranet. The API, when called, instantiates business objects, such as a catalog service entity provider for listing products from a catalog or a purchasing service entity provider for allowing the purchase of a product.
Business logic encapsulated in a business object may be decoupled from business scenario-specific requirements. The business logic encapsulation may be governed by business-driven functionality requirements, leading to a normalized approach. Typically, the encapsulated business logic is designed independent of user-interface (UI) requirements. The business logic encapsulation is instead designed to provide a stable interface and maximum reusability. In contrast, a user interface requirement is typically governed by the user's perspective in a specific scenario. Thus, in different user interface scenarios, user interface requirements may require different parts of a business object or even parts from separate business objects. For example, a user interface specific scenario for displaying items in a sales order may rely on both a sales order business object for accessing the sales order and a product information business object for retrieving product information related to the items in the sales order.
A declarative approach may also be utilized for stable interfaces and maximum reuse of an algorithm. The declarative approach may separate the logic of the algorithm from the control of an algorithm. A user may specify, via a declaration, the logic or equations indicating the relations to be solved, but the computing system may be responsible for the control and/or evaluation of the logic or equation. Examples of the declarative approach are spreadsheets and query languages for relational databases. The user specifies a mathematical relation as a declaration (e.g., a query based on structured query language, or SQL) for retrieving data from a database, while a database system determines how to execute the query against the database.
In the view of the foregoing, there is a need for systems and methods that bridge the gap between scenario-specific requirements in an user interface view and business logic encapsulated in business objects during the user interface construction process. Further, there is a need for additional functionality to harmonize the fine-granular encapsulation (e.g., user interface view) with the coarse external service level (e.g., Web services, service entities, etc.). It is desirable that such systems and methods enable adaptation of service entities using a declarative approach in a service framework.